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Abstract 

To appear in Theory and Practice of Logic Programming (TPLP). In this paper we discuss 
the optimizing compilation of Constraint Handling Rules (CHRs). CHRs are a multi- 
headed committed choice constraint language, commonly applied for writing incremental 
constraint solvers. CHRs are usually implemented as a language extension that compiles 
to the underlying language. In this paper we show how we can use different kinds of 
information in the compilation of CHRs in order to obtain access efficiency, and a better 
translation of the CHR rules into the underlying language, which in this case is HAL. The 
kinds of information used include the types, modes, determinism, functional dependencies 
and symmetries of the CHR constraints. We also show how to analyze CHR programs to 
determine this information about functional dependencies, symmetries and other kinds of 
information supporting optimizations. 

1 Introduction 

Constraint handling rules IjFriihwirth 1998|l (CHRs) are a very flexible formalism 
for writing incremental constraint solvers and other reactive systems. In effect, 
the rules define transitions from one constraint set to an equivalent constraint set. 
Transitions serve to simplify constraints and detect satisfiability and unsatisfiabil- 
ity. CHRs have been used extensively (see e.g. (|Holzbaur and Friihwirth 2000(1 L 
Efficient implementations have been available for many years in the languages SIC- 
Stus Prolog and ECL'PS'^, and implementations for other languages are appearing 
such as Java IjJCK 2002|l and HAL. 

In this paper we discuss how to improve the compilation of CHRs by using 
additional information derived either from declarations provided by the user or from 
the analysis of the constraint handling rules themselves. The major improvements 

* A preliminary version of this paper appeared under the title "O ptimizing; Co m pilation of Con- 
straint Handling Rules" in ICLP 2001, Cyprus, November 2001 IHolzbaur et al. 20011 . 
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we discuss over previous work on CHR compilation (|Holzbaur and Friihwirth 2000|l 
are: 

• general index structures which are specialized for the particular joins required 
in the CHR execution. Previous CHR compilation was restricted to two kinds 
of indexes: simple lists of constraints for given Name/Arity and lists indexed 
by the variables involved. For ground usage of CHRs this meant that only list 
indexes are used. 

• continuation optimization, where we use matching information from rules 
earlier in the execution to avoid matching later rules. 

• optimizations that take into account algebraic properties such as functional 
dependencies, symmetries and the set semantics of the constraints. 

We illustrate the advantages of the various optimizations experimentally on a num- 
ber of small example programs in the HAL implementation of CHRs. We also discuss 
how the extra information required by HAL in defining CHRs (that is, type, mode 
and determinism information) is used to improve the execution. 

In part some of the motivation of this work revolves around a difference between 
CHRs in Prolog and in HAL. HAL is a typed language which does not (presently) 
support attributed variables. Prolog implementations of CHRs rely on the use of 
attributed variables to provide efhcient indexing into the constraint store. Hence, 
we are critically interested in determining efficient index structures for storing con- 
straints in the HAL implementation of CHRs. An important benefit of using specific 
index structures is that CHRs which are completely ground can still be efficiently 
indexed. This is not exploited in the current Prolog implementations. As some CHR 
solvers only use ground constraints this is an important issue. 

The remainder of the paper is organized as follows. In the next section we give 
preliminary definitions, including the operational semantics of constraint handling 
rules. In Section|31we go through the basic steps involved in compiling a set of con- 
straint handling rules, and see how we can make use of properties such as functional 
dependencies and symmetry and set semantics in improving this basic compilation. 
In Section^ we show how we can improve the compilation of a set of CHRs by dis- 
covering properties of constraints by reasoning about the form of the rules defining 
them. In Section[Slwe show how to infer the functional dependencies and symmetry 
information, used in Section O from a set of CHRs. In Section Owe give our exper- 
imental results illustrating the advantages of the optimized compilation. Finally, in 
Section [7| we conclude. 



Constraint Handling Rules manipulate a global multiset of primitive constraints, 
using multiset rewrite rules which can take three forms 
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where name is an optional rule name, ci, . . . , c„ are CHR constraints, g is a conjunc- 
tion of constraints from the underlying language, and di, . . . , dm is a conjunction 
of CHR constraints and constraints of the underlying language. The guard part g 
is optional. If omitted, it is equivalent to g = true. 

The simplification rule states that given a constraint multiset {c'l, . . . ,c^} and 
substitution matching the multiset {ci, . . . , c„}, i.e. {c'l, . . . , c'„} = 0{{ci, . . . , c„}), 
where the execution of 9{g) succeeds, then we can replace {c[, . . . , c^} by multi- 
set 9{{di, . . . ,dm})- The propagation rule states that, for a matching constraint 
multiset {c'^, . . . , c^} where 9{g) succeeds, we should add 9{{di, . . . , d,n})- The sim- 
pagation rules states that, given a matching constraint multiset {c'l, . . . , c'„} where 
0{g) succeeds, we can replace {cj^j^, . . . , c'„} by 0{{di, . . . , dm})- A CHR program is 
a sequence of CHRs. 

More formally the logical interpretation of the rules is as follows. Let x be the 
variables occurring in {ci, . . . , c„}, and y (resp. z) be the other variables occurring 
in the guard g (resp. rhs di, . . . , dm) of the rule. We assume no variables not in x 
appear in both the guard and the rhs.^ The logical reading is 

simplification Vx(3^ .g) — » (ci A • • ■ A c„ ^ {3z di A • ■ • A dm)) 
propagation yx{3y 5) — *■ (ci A • • • A c„ {3z di A ■ ■ ■ A dm)) 
simpagation Vx(3y 5) ^ (ci A ■ • ■ A c„ ^ {3z ci A • ■ • A q A di A • ■ • A dm)) 

The operational semantics of CHRs exhaustively apply rules to the global multiset 
of constraints, being careful not to apply propagation rules twice on the same con- 
straints (to avoid infinite propagation). For more details sec e.g. fAbd ennadher 1997|l 
Although CHRs have a logical reading (see e.g. (p^riihwirth 1998)), and program- 
mers are encouraged to write confluent CHR programs, there are applications where 
a predictable order of rule applications is important. Hence, the textual order of 
rules in the program is used to resolve rule applicability conflicts in favor of earlier 
rules. 

The operational semantics is a transition system on a triple (s, h,t)y of a set of 
(numbered) CHR constraints s, a conjunction of Herbrand constraints h, and a set 
of transitions applied, as well as a sequence of variables v. The logical reading of 
(s, h,t)y is as 3y{s A h) where y are the variables in the tuple not in v. Since the 
variable component v never changes we omit it for much of the presentation. 

The transitions are defined as follows: Given a rule numbered a and a tuple 
(s, h,t)y 



where di, . . . , are CHR literals and d^+i, ■ ■ ■ , dm are Herbrand constraints, such 
that there are numbered literals {c^^, . . . , c^^} C s where \= h —>■ 3xci — Ci-^ A 
■ ■ ■ A Cn = Ci„ and there is no entry (ii, . . . , i„, a) in t then the transition can be 
performed to give new state (sU{(ii, . . . , dfc}, hAdk+iA - ■ ■ Ad™, tU{(ii, . . . , i„, a)})^ 
where the new literals in the first component are given new id numbers. 




^ This allows us to more easily define the logical reading, we can always place a CHR in this form, 
by copying parts of the guard into the right hand side of the rule and renaming. 
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The rule for simplification is simpler. Given a tuple (s, h, t)y and a rule 

Ci , . . . , c„ ■^=!> g I di, . . . ,dk, dk+i , . . . ,dm 

such that there are literals {c^^ , . . . , c^^ } C s where ft- — » 3xci = A - • • Ac„ = Ci^ 
the resulting tuple is (s \ {c-^, . . . , c-^} U {di, . . . , dk}, h A dk+i A • ■ • A dm,t)v ■ 

In this paper we focus on the implementation of CHRs in a programming lan- 
guage, such as HAL IjDemoen et al. 1999|l . which requires programmers to provide 
type, mode and determinism information. A simple example of a HAL CHR pro- 
gram to compute the greatest common divisor of two positive numbers a and b 
(using the goal gcd(a) , gcd(6)) is given below. 



:- module gcd. (-^'1) 

:- import int. {L2) 

:- chr .constraint gcd/1. (-^'3) 

:- export pred gcd(int) . (^4) 

:- mode gcd(in) is det . (^5) 

base @ gcd(O) <=> true. (1/6) 

pair ® gcd(N) \ gcd(M) <=> M >= N I gcd(M-N) . (L7) 



The first line {LI) states that the file defines the module gcd. Line {L2) imports the 
standard library module int which provides (ground) arithmetic and comparison 
predicates for the type int. Line (i3) declares the predicate gcd/1 to be imple- 
mented by CHRs. Line {LA) exports the CHR constraint gcd/1 which has one 
argument, an int. This is the type declaration for gcd/1. Line {L5) is an example 
of a mode of usage declaration. The CHR constraint gcd/l's first argument has 
mode in meaning that it will be fixed (ground) when called. The second part of the 
declaration "is det" is a determinism statement. It indicates that gcd/1 always 
succeeds exactly once (for each separate call). For more details on types, modes 
and determinism see l|Demoen et al. 1999 [Somogyi et al. 19961 ). 

Lines {L6) and (L7) are the 2 CHRs defining the gcd/1 constraint. The first 
rule is a simplification rule. It states that a constraint of the form gcd(O) should 
be removed from the constraint store to ensure termination. The second rule is a 
simpagation rule. It states that given two different gcd/1 constraints in the store, 
such that one gcd(M) has a greater argument than the other gcd(N) we should 
remove the larger (the one after the \), and add a new gcd/1 constraint with 
argument M-N. Note that M-N is the result of the subtraction of integer N from M, 
not the term -(M,N) that would be created in Prolog. Together these rules mimic 
Euclid's algorithm. 

The requirement of the HAL compiler to always have correct mode information 
means that CHR constraints can only have declared modes that do not change 
the instantiation state of their arguments,^ since the compiler will be unable to 
statically determine when rules fire. Hence for example legitimate modes are in, 
which means the argument is fixed at call time and return time, and oo, which 
means that the argument is initialized at call time, but nothing further is known, 



They may actually change the instantiation state but this cannot be made visible to the mode 
system. 



Optimizing Compilation of Constraint Handling Rules in HAL 



5 



and similarly at return time. The same restriction applies to dynamically scheduled 
goals in HAL (see IjPemoen et al. 1999|l '). 

3 Optimizing the basic compilation of CHRs 

Essentially, the execution of CHRs is as follows. Every time a new constraint (the 
active constraint) is placed in the store, we search for a rule that can fire given 
this new constraint, i.e., a rule for which there is now a set of constraints that 
matches its left hand side. The first such rule (in the textual order they appear in 
the program) is fired. 

Given this scheme, the bulk of the execution time for a CHR 

Ci, . . . , C;[, \]c; + i, . . . , C„ g\di,...,dm 

is spent in determining partner constraints c'j^, . . . , c^_-^, c[_^^^, ■ ■ ■ ic'„ for an active 
constraint to match the left hand side of the CHR. Hence, for each rule and 
each occurrence of a constraint, we are interested in generating efficient code for 
searching for partners that will cause the rule to fire. We will then link the code for 
each instance of a constraint together to form the entire program for the constraint. 
In this section, when applicable, we will show how different kinds of compile-time 
information can be used to improve the resulting code in the HAL version of CHRs. 

3.1 Join Ordering 

The left hand side of a rule together with the guard defines a multi-way join with 
selections (the guard) that could be processed in many possible ways, starting from 
the active constraint. This problem has been extensively addressed in the database 
literature. However, most of this work is not applicable since in the database context 
they assume the existence of information on cardinality of relations (number of 
stored constraints) and selectivity of various attributes. Since we are dealing with 
a programming language we have no access to such information, nor reasonable 
approximations. Another important difference is that, often, we are only looking 
for the first possible join partner, rather than all. In the SICStus CHR version, 
the calculation of partner constraints is performed in textual order and guards are 
evaluated once all partners have been identified. In HAL we determine a best join 
order and guard scheduling using, in particular, mode information. 

Since we have no cardinality or selectivity information we will select a join or- 
dering by using the number of unknown attributes in the join to estimate its cost. 
Functional dependencies are used to improve this estimate, by eliminating unknown 
attributes from consideration that are functionally defined by known attributes. 

Functional dependencies are represented as p{x) :: S x where S U {x} C 
X meaning that for constraint p fixing all the variables in S means there is at 
most one solution to the variable x. The function fdc\ose{Fixed,FDs) closes a 
set of fixed variables Fixed under the finite set of functional dependencies FDs. 
fdc\ose{Fixed,FDs) is the least set F D Fixed such that for each {p{x) :: S x) £ 
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FDs such that S C F then x E F. Clearly the fixedpoint exists, since the operation 
is monotonic. 

We assume an initial set Fixed of known variables (which arises from the active 
constraint), together with the set of (as yet unprocessed) partner constraints and 
guards. The algorithm measure shown in Figure ^ takes as inputs the set Fixed, 
the sequence Partners of partner constraints in a particular order, the set FDs 
of functional dependencies, and the set Guards of guards and returns the triple 
{score, Goal, Lookups). 

The score is an ordered pair representing the cost of the join for the particular 
order given by the n partner constraints in Partners. It is made up of the weighted 
sum (n — \)wi + {n — 2)w2 + • • • + lwn~i of the costs Wi for each individual join with 
a partner constraint. The weighting encourages the cheapest joins to be earliest. 

The cost of joining the i*'' partner constraint to pre-join expression (the join 
of the active constraint plus the first (i — 1) partners), Wi, is defined as the pair 
(u, /): u is the number of arguments in the new partner which are unfixed before 
the join; and / is the negative of the number of arguments which are fixed in 
the pre-join expression. The motivation for this costing is based on the worst case 
size of the join, assuming each argument ranges over a domain of the same size 
s. In this case the number of join partners (tuples) in the partner constraint for 
each set of values for the pre-join expression is s", and there are s™'~^ tuples in 
the pre-join expression (where ni is the total number of variables in the pre-join 
expression). The total number of tuples after the i*'' partner is joined are thus 
g-m-f+u^ The numbers hence represent the exponents of the join size, a kind of 
"degrees of freedom" measurement. The sum of the first components u gives the 
total size of the join. The role of the second component is to prefer orderings which 
keep the intermediate results smaller. 

We also take into account the selectivity of the guards we can schedule directly 
after the new partner. This is achieved via the selectivity{Guards) function which 
returns the sum of the selectivities of the guards Guards. The selectivity of a 
equational guard X = y is 1 provided X and Y are both fixed, otherwise the 
selectivity is 0. An equation with both X and Y fixed immediately eliminates one 
degree of freedom (reduces the number of tuples by 1/s), hence the selectivity of 
1. When one variable is not fixed, the guard does not remove any answers. For 
simplicity, the selectivity of other guards is considered to be 0.5 (as motivation, 
the constraint X > Y where X and Y can be considered to remove 0.5 degrees 
of freedom). The role of selectivity is to encourage the early scheduling of guards 
which are likely to fail. 

Goal gives the ordering of partner constraints and guards (with guards scheduled 
as early as possible). Finally, Lookups gives the queries. Queries will be made from 
partner constraints, where a variable name indicates a fixed value, and an under- 
score (_) indicates an unfixed value. For example, query p(X,_,X,Y,_) indicates a 
search for p/5 constraints with a given value in the first, third, and fourth argument 
positions, the values in the first and third position being the same. 

The function schedule_guards(F,G) returns which guards in G can be scheduled 
given the fixed set of variables F. Here we see the usefulness of mode information 



Optimizing Compilation of Constraint Handling Rules in HAL 



7 



measure{Fixed,Partner s ,F Ds , Guards) 

Lookups := 0; score :— (0,0); sum := (0,0) 
Goal :— schedule_guards(Fia;ed, Guards) 
Guards := Guards \ Goal 
while true 

if Partners = return {score, Goal, Lookups) 

let Partners = p{x), Partner si 

Partners :— Partnersl 

FDp ■- {p{x) :: fd G FDs} 

Fixedp := fdc\ose{Fixed, FDp) 

f := xO Fixedp 

Fixed := Fixed U x 

GsEarly := schedule_guards(Fia;ed, Guards) 

cost := {max(\x \ f\ — selectivity{GsEarly) ,0) , — 1/| — selectivity{GsEarly)) 
score := score + sum + cost; sum := sum + cost 
Lookups := Lookups U {p{{xi € f 1 Xi : _) | Xj € x)} 
Goal := Goal, p{x), GsEarly; 
Guards ~ Guards \ GsEarly 
endwhile 

return {score. Goal, Lookups) 

schedule_guards(-F,G) 
S := 
repeat 
Go := G 
foreach g € G 

if invar s{g) C F 
S := S,g 

F := F U outvars{g) 

G:=Gs\ {g} 
until Go = G 
return S 



Fig. 1. Algorithm for evaluating join ordering 



which allows us to schedule guards as early as possible. For simplicity, we treat 
mode information in the form of two functions: invars and outvars which return 
the set of input and output arguments of a guard procedure. We also assume that 
each guard has exactly one mode (it is straightforward to extend the approach to 
multiple modes and more complex instantiations). The schedule_guards keeps adding 
guards to its output argument while they can be scheduled. 

The function measure works as follows: beginning from an empty goal, we first 
schedule all possible guards. We then schedule each of the partner constraints p{x) 
in Partners in the order given, by determining the number of fixed (/) and unfixed 
{x \ f) variables in the partner, and the selectivity of any guards that can be 
scheduled immediately afterwards. With this we calculate the cost pair for the join 
which is added into the score. The Goal is updated to add the join p{x) followed 
by the guards that can be scheduled after it. When all partner joins are calculated 
the function returns. 
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Example 1 

Consider the compilation of the rule: 

p(X,Y), q(Y,Z,T,U), flag, r(X,X,U) \ s(W) ==> W = U + 1 , linear(Z) I p(Z,W) . 

for active constraint p(X,Y) and Fixed = {X, F}. The individual costs calculated 
for each join in the left-to-right partner order illustrated in the rule are (2.5, —1.5), 
(0, 0), (0, —2), (0, —1) giving a total cost of (10, —11) together with goal 

q(Y,Z,T,U), W = U + 1, linear(Z), flag, r(X,X,U), s(W) 

and lookups q(Y, _,_,_), flag, r(X,X,U), s(W). The best order has total cost 
(4.5, —7.5) resulting in goal 

flag, r(X,X,U), W = U + 1, s(W), q(Y,Z,T,U), linear(Z) 

and lookups flag, r(X,X,_), s(W), q(Y,_,_,U). 

For active constraint q(Y,Z,T,U), the best order has total cost (2, —8) resulting 
in goal 

W = U + 1, linear(Z), s(W), flag, p(X,Y), r(X,X,U) 

and lookups s(W), flag, p(_,Y), r(X,X,U). □ 

For rules with large-left-hand sides where examining all permutations is too ex- 
pensive we can instead greedily search for a permutation of the partners that is 
likely to be cost effective. The current HAL implementation uses this method. In 
practice, both methods usually find the best ordering because the left-hand-sides 
of CHRs are generally small. 

3.2 Index Selection 

Once join orderings have been selected, we must determine for each constraint a 
set of lookups of constraints of that form in the store. We then select an index or 
set of indexes for that constraint that will efficiently support the lookups required. 
Finally, we choose a data structure to implement each index. Mode information is 
crucial to the selection of index data structures. If the terms being indexed on are 
not ground, then we cannot use tree indexes since variable bindings will change the 
correct position of data.^ 

The current SICStus Prolog CHR implementation uses only two index mecha- 
nisms: Constraints for a given Functor/Arity are grouped, and variables shared 
between heads in a rule index the constraint store because matching constraints 
must correspondingly share a (attributed) variable. In the HAL CHR version, we 
put extra emphasis on indexes for ground data: 

The first step in this process is lookup reduction. Given a set of lookups for con- 
straint p/A; we reduce the number of lookups by using information about properties 
of p/fc: 



^ Currently HAL only supports CHRs with fixed arguments (although these might be variables 
from another (non-Herbrand) solver). 
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• lookup generalization: rather than build specialized indexes for lookups that 
share variables we simply use more general indexes. Thus, we replace any 
lookup p{vi,...,Vk) where Vi and Vj are the same variable by a lookup 
p(f 1 , . . . , I'j-i , v'^ , Vj+i , ■ ■ ■ ,i^k) where v'^ is a new variable. Of course, we must 
add an extra guard Vi — Vj for rules where we use generalized lookups. For 
example, the lookup r (X , X , U) can use the lookup for r (X , XX , U) , followed by 
the guard X = XX. 

• functional dependency reduction: we can use functional dependencies to re- 
duce the requirement for indexes. We can replace any lookup p(vi, . . . 
where there is a functional dependency . . . ,Xk) ■■ {xi^^, . . . ,Xi^^^} xj 
and , . . . , are fixed variables (i.e. not _) by the lookup 
p(wi, . . . , fj-i, _, Vj+i, . . . , Vk)- For example, consider the constraint 
bounds (X , L , U) which stores the lower L and upper U bounds for a constrained 
integer variable X. Given functional dependency bounds {X, L,U) :: X L, 
the lookup bounds (X,L,_) can be replaced by bounds (X,_,_). 

• symmetry reduction: if p/fc is symmetric on arguments i and j we have two 
symmetric lookups p{vi,. . . ,Vi, . . . ,Vj, . . . , Vk) and p(wj , . . . , u-, . . . , , . . . , w^) 
where vi = v'l for \ < I < k,l ^ i,l ^ j and Vi = v'j and Vj = v[ then remove 
one of the symmetric lookups. For example, if eq/2 is symmetric the lookup 
eq(_,Y) can use the index for eq(X,_). 

We discuss how we generate functional dependency and symmetry information 
in Section [S] We can now choose the data structures for the indexes that support 
the remaining lookups. 

Normally, the index will return an iterator which iterates through the multi- 
set of constraints that match the lookup. Conceptually, each index thus returns 
a list iterator of constraints matching the lookup. We can use functional depen- 
dencies to determine when this multiset can have at most one element. This is 
the case for a lookup p(wi, . . . , Wfc) with fixed variables Vi^, . . . , Vi^ such that fd- 
c\o5e{{xi-^, . . . , Xi^}, FDp) 3 {xi, . . . ,Xk} where FDp are the functional depen- 
dencies for p/fc, since in this case the functional dependencies ensure that for fixed 
Vi-^ , . . . , Vi^^ there can be at most one tuple in the constraint. For example, the 
lookup bounds (X,_,_) returns at most one constraint given the functional depen- 
dencies: bounds{X, L,U) :: X L and bounds{X, L,U) :: X U. 

Since, in general, we may need to store multiple copies of identical constraints 
(CHR rules accept multisets rather than sets of constraints) each constraint needs 
to be stored with a unique identifier, called the constraint number. Code for the 
constraint will generate a new identifier for each new active constraint. Constraints 
that cannot have multiple copies stored at once are said to have set semantics (see 
section [4. 4|) . In this case constraint numbers are not strictly necessary. 

Each index for p(wi, . . . , Wfe), where say the fixed variables are , . . . , vt^ , needs 
to support the following operations: 

: - pred p_index_init . 

:- mode p_index_init is det . 

:- pred p_index_insert (argl , argk, constraint_num) . 

:- mode p_index_insert (in, in, in) is det. 
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:- pred p_index_delete(argl, argk, constraint_num) . 

:- mode p_index_delete(iii, in, in) is det . 

:- pred p_index_init_iterator (argil , argim, iterator). 

:- mode p_index_init_iterator (in, in, out) is det. 

for initializing a new index, inserting and deleting constraints from the index 
and returning an iterator over the index for a given lookup. Note that the con- 
straint number is an important extra argument for index manipulation. In HAL 
indexes are stored in global variables, which are destructively updated for initial- 
ization, deletions and insertions. The compiler generates code for the predicates 
p_insert_constraint and p_delete_constraint which insert and delete the con- 
straint p from each of the indexes in which it is involved. 

The current implementation supports three kinds of index structures: 

• A yesno global variable 

• A balanced 234 tree 

• An unsorted list (the default) 

By far the simplest index structure is a yesno global variable, which can have two 
states: a no state (meaning nothing is currently stored) or a yes (C) state, where C is 
the only constraint currently in the store. The compiler will generate a yesno index 
structure whenever it detects that it is not possible for multiple^ p/ k constraints to 
exist in the store at once. This is the case whenever constraint p/k has set semantics 
(no identical copies) and has the functional dependencies p{x) :: ~^ for Xi € x 
(all copies must be identical) . An example is the constraint gcd/ 1 from the gcd 
example program in Section |21 Here the rule 

gcd(N) \ gcd(M) <=> M >= N I gcd(M-N) . 

ensures one of the two gcd/2 constraints (one must be active) will be deleted. 
Therefore only one can ever actually be in the store at once, hence a yesno index 
structure may be used. 

If constraint p/k has set semantics and functional dependencies of the form 
p(a;i, . . . , Xi, Xi+i, . . . , Xfc) :: {xi, . . . ,Xi} ^ xj for all i < j < k then the com- 
piler will generate a balanced 234 tree index structure. In this case the constraint 
p/fc can be thought of as defining a function from the key {xi, . . . ,Xi) to a value 
{xi^i, . . . , Xk). For example, the constraint bounds(X,L,U) from the program in 
Figure IXn in Appendix A has the functional dependencies bounds{X, L,U) :: X 
L and bounds{X, L, U) :: X U, hence the compiler builds a 234 tree index 
structure with X as the key, and the tuple (L,U) as the value. In addition, if the 
constraint p/fc has set semantics, but has no functional dependency, then we can 
still use a tree index by treating the entire constraint as the key. For example, the 
constraint X != Y from the interval program in Appendix A has set semantics. 

These constraints do not have to be identicaL 
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thus we can use a tree structure with (X,Y) as the key, and the empty set as the 
value. 

The big advantage of tree structures is 0(log(n)) lookups whenever the key is 
fixed, compared with 0{n) lookups for unsorted lists. Even if the key is only partially 
fixed there is still a potential for considerable benefit. Suppose that {X, Y) is the 
key, then all keys of the form {X, _) will group together in the tree index because 
of HAL's default groimd term ordering. As a result, wc can still do fast searches by 
pruning large sections of the tree that are not of interest. The same is not true for 
keys of the form (_, Y) but we can sometimes use symmetric reduction to do the 
faster {Y, _) lookup instead. 

Example 2 

The CHR constraint ! =/2 defined by rules 
neqsym @ X != Y ==> Y != X. 

neqlower @ X != Y, bounds (X, VX, VX) , bounds (Y,VX,UY) ==> bounds(Y,VX+l,UY) . 
nequpper @ X != Y, bounds (X, VX, VX) , bounds (Y.LY.VX) ==> bounds (Y, LY, VX-1) . 

has lookups ! = (X,_) and ! = (_,Y), and !=/(X,Y) and is known to be symmetric in 
its two arguments. Wc can remove the lookup ! = (_,Y) in favor of the symmetric 
! = (Y,_), and then use a single balanced tree index for ! = (X,Y) to store !=/2 
constraints since this can also efficiently retrieve constraints of the form ! = (X,_). 
□ 

The advantage of using a tree is lost whenever there is a lookup which is not a 
prefix of the index. These lookups can be implemented using universal search over 
the tree, but this is particularly bad, since we need to construct a tree iterator, 
which is currently implemented as a tree to list conversion with high overhead. For 
simplicity, we currently do not use tree indices when at least one lookup is not a 
prefix of the key. Fortunately universal searches against the direction of the func- 
tional dependency are relatively rare in practice, and in the future implementations 
of universal searches might do away with the need for iterators altogether. 

The third and final type of index structure is an unsorted list. The advantage 
of a list index is fast 0(1) insertions, but the disadvantages are slow 0{n) lookups 
and deletions. However, if a constraint p/A; is never deleted, and is often involved 
in universal searches, then a list is a logical choice for the index structure. 

3. 3 Code generation for individual occurrences of active constraints 

Once we have determined the join order for each rule and each active constraint, 
and the indexes available for each constraint, we are ready to generate code for 
each occurrence of the active constraint. Two kinds of searches for partners arise: 
A universal search iterates over all possible partners. This is required for propaga- 
tion rules where the rule fires for each possible matching partner. An existential 
search looks for only the first possible set of matching partners. This is sufficient 
for simplification rules where the constraints found will be deleted. 

We can split the constraints appearing on the left-hand-side of any kind of rule 
into two sets: those that are deleted by the rule [Remove), and those that are not 
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bouiids_4(X,Ll,Ul,CNl) :- 

(bounds_index_exi St s_it erat ion (X , _ , L2 , U2 , CN2) , 
CNl != CN2 -> 

bounds_remove_constraiiit (X,L1 ,U1 ,CN1) , 
bounds_remove_constraiiit (X , L2 , U2 , CN2) , 
bounds(X,min(Ll,L2) ,max(Ul,U2)) , 7,7, RHS 
bounds_4_succ_cont (X , LI , Ul , CNl) 

bounds_4_fail_cont(X,Ll,Ul,CNl) 7.7. try next rule 

). 

Fig. 2. Existential search code for the fourth occurrence of a bounds/3 constraint 

(Keep). The partner search uses universal search behavior, up to and including the 
first constraint in the join which appears in Remove. From then on the search is 
existential. If the constraint has a functional dependency that ensures that there 
can be only one matching solution, wc can replace universal search by existential 
search. 

For each partner constraint we need to choose an available index for finding 
the matching partners. Since we have no selectivity or cardinality information, we 
simply choose the index with the largest intersection with the lookup. 

Example 3 

Consider the compilation of the 1st occurrence of the bounds/3 constraint in the 
rule (the fourth occurrence overall in the program in Figure lA 111 

intersect @ bounds (X, LI ,U1) .bounds (X,L2 ,U2) <=> 

bounds(X,max(Ll,L2) ,min(Ul ,U2) ) . 

Since the active constraint is in Remove the entire search is existential. The com- 
pilation produces the code in Figure [3 

The predicate bounds_index_exists_iteration iterates non-deterministically 
through the bounds/3 constraints in the store using the index on the first argument. 
In the last 4 arguments it returns the 3 arguments of bounds/3 as well as a unique 
constraint number identifying the instance of the bounds/3 constraint.^ Note we 
check that the matching bounds /3 constraint has a different constraint number 
than the active constraint CNl != CN2. The predicate bounds jremove_constraint 
removes the bounds/3 from the store. If the matching succeeds, then afterwards we 
call the success continuation bounds_4_succ_cont (which will later be replaced by 
true), otherwise we call the failure continuation bounds_4_f ail_cont. 

The compilation for first occurrence of a bounds /3 constraint in the rule (the 
second occurrence overall) 

redundant (§ bounds (X, LI ,U1) \ bounds (X,L2,U2) <=> LI >= L2, Ul <= U2 I true. 

requires universal search for partners since it is not deleted if the rule succeeds. The 
compilation produces the code shown in Figure |2| 



^ The iterator need only return the last 2 arguments of bounds/3 and the constraint number, 
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bounds_2(X,Ll,Ul,CNl) :- 

bounds_index_init_iterator (X, 10) , 
bounds_2_f orall.iterate (X , LI , Ul , CNl , 10) , 
bounds_2_cont(X,Ll,Ul,CNl) . 

bomids_2_f orall_iterate (X , LI , Ul , CNl , 10) : - 
bounds_iteration_last (10) , 
bounds_3(X,Ll,Ul,CNl) . 
bounds_2_f orall_iterate (X , LI , Ul , CNl ,10) : - 

bounds_iterat ion_next ( 10 , _ , L2 , U2 , CN2 ,11), 
(LI >= L2, Ul <= U2, CNl != CN2 -> 7,7. Guard 

bounds_remove_constraint(X,L2,U2,CNl) , 7,7, remove matched constraint 
true 7.7. RHS 

true /,'/, rule did not apply 

), 

(bounds_alive(CNl) -> 

bounds_2_f orall_iterate (X , LI , Ul , CNl , 1 1) 

true /,'/, active has been deleted 

). 



Fig. 3. Universal search code for the second occurrence of a bounds/3 constraint 

The predicate bounds_index_init_iterator, returns an iterator of bounds/3 
constraints resulting from looking up the index. bounds_iteration_last and 
bounds_iteration_next respectively succeed if the iterator is finished and return 
values of the next bounds /3 (and its constraint number) as well as the new iter- 
ator. After the rule has fired, the predicate bounds_alive checks that the active 
constraint has not been deleted as a consequence of executing the right-hand-side. 
If the active constraint is still alive, then we continue looking for more match- 
ings. Note that for universal search we (presently) do not separate fail and success 
continuations. □ 

Example 4 

Consider the compilation of the 3rd occurrence of a gcd/ 1 constraint in the program 
in the introduction (the second occurrence in {LI)) which is to be removed. Since the 
active constraint is in Remove the entire search is existential. The compilation pro- 
duces the code gcd_3 shown in Figure^ The predicate gcd_index_exists_iteration 
iterates non-detcrministically through the gcd/ 1 constraints in the store using the 
index (on no arguments). It returns the value of the gcd/1 argument as well as 
its constraint number. Next, the guard is checked. Additionally, we check that the 
two gcd/ 1 constraints are in fact different by comparing their constraint numbers 
(CNl ! = CN2). If a partner is found, the active constraint is removed from the store, 

since the first argument must be known, but the compilation is more straightforward if it 
always returns all arguments. 
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gcd_3(M,CNl) :- 



gcd_2_f orall.iterate (N , CNl ,10) : - 
gcd_iteration_last (10) , 
gcd_insert_constraint(N,CNl) . 



(gcd_index_exists_iteration(N,CN2) , 



M >= N, CNl != CN2 -> 7.7, guard 
gcd_delete_constraint(M,CNl) , 
gcd(M-N) , 7.7. RHS 
gcd_3_succ_cont(M,CNl) 

; gcd_3_fail_cont(M,CNl) ). 



gcd_2_f orall.iterate (N , CNl ,10) : - 

gcd_iterati on_next (I0,M,CN2,I1), 
(M >= N, CNl != CN2 -> 7,7. guard 



gcd_delete_constraint(M,CN2) , 



gcd(M-N) 7.7, RHS 



gcd_2(N,CNl) :- 

gcd_index_init_iterator (10) , 
gcd_2_f orall.iterate (N , CNl , 10) , 
gcd_2_cont(N,CNl) . 



true 7.7. rule did not apply 

), 

(gcd_alive(CNl) -> 

gcd_2_f orall.iterate (N , CNl ,11) 



true 



). 



Fig. 4. Code for existential partner search and universal partner search. 

and the body is called. Afterwards, the success continuation for this occurrence is 
called. If no partner is found the failure continuation is called. 

The compilation for second occurrence of a gcd/ 1 constraint (the first occur- 
rence in {L7)) requires universal search for partners. The compilation produces 
the code gcd_2 shown in Figure^ The predicate gcd_index_init_iterator, re- 
turns an iterator of gcd/ 1 constraints resulting from looking up the index. Calls 
to gcd_iteration_Last and gcd_iteration_next succeed if the iterator is finished 
and return values of the last and next gcd/ 1 constraint (and its constraint number) 
as well as the new iterator. □ 

3.4 Joining the code generated for each constraint occurrence 

After generating the code for each individual occurrence, we must join it all together 
in one piece of code. The occurrences are ordered by textual occurrence except for 
simpagation rules where occurrences after the \ symbol are ordered earlier than 
those before the symbol (since they will then be deleted, thus reducing the number 
of constraints in the store). Let the order of occurrences be oi, . . . , Om- The simplest 
way to join the individual rule code for a constraint p/k is as follows: Code for p/fc 
creates a new constraint number and calls the first occurrence of code p_oi/fc -I- 1. 
The fail continuation for p_Oj/fc + 1 is set to p_Oj+i/fc + 1. The success continuation 
for p_Oj/k -|- 1 is also set to p_Oj+i//c -I- 1 unless the active constraint for this 
occurrence is in Remove in which case the success continuation is true, since the 
active constraint has been deleted. 

Example 5 

For the gcd program the order of the occurrences is 1,3,2. The fail continuations 
simply reflect the order in which the occurrences are processed: gcd_l continues 
to gcd_3 which continues to gcd_2 which continues to true. Clearly, the success 
continuation for occurrences 1 and 3 of gcd/1 are true since the active constraint 
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gcd(N) :- 

new_constraint_number (CNl) , 

gcd_insert_constraint (N, CNl) , 

gcd_l(N,CNl) . 
gcd_l(N,CNl) :- 

(N = -> %7, Guard 

gcd_delete_constraint(N,CNl) , 
true, y.y. RHS 
gcd_l_succ_cont (N, CNl) 

; gcd_l_fail_cont(N,CNl)) . 



gcd_l_succ_cont (_, _) . 
gcd_l_f ail.cont (N , CNl) 

gcd_3_succ_cont (_, _) . 
gcd_3_f ail.cont (N , CNl) 

gcd_2_cont (_, _) . 



gcd_3(N,CNl) , 
gcd_2(N,CNl) , 



Fig. 5. Initial code, code for first occurrence and continuation code for gcd 



is deleted. The continuation of gcd_2 is true since it is last. The remaining code 
for gcd/1 is given in Figure El^ □ 



4 Improving CHR compilation 

In the previous section we have examined the basics steps for compiling CHRs tak- 
ing advantage of type, mode, functional dependency and symmetries information. 
In this section we examine other kinds of optimizations that can be performed by 
analysis of the CHRs. 



4-1 Continuation optimization 

We can improve the simple strategy for joining the code generated for each occur- 
rence of a constraint by noticing correspondences between rule matchings for various 
occurrences. Suppose we have two consecutive occurrences with active constraints, 
partner constraints and guards given by the triples (p{x)^c,g) and (j>iy), c' , g') re- 
spectively. Suppose we can prove that \= {x = y A{3yc' Ag')) 3xcAg (where 3vF 
indicates the existential quantification of F for all its variables not in set V). Then, 
anytime the first occurrence fails to match the second occurrence will also fail to 
match, since the store has not changed meanwhile. Hence, the fail continuation for 
the first occurrence can skip over the second occurrence. 

Example 6 

Consider the following rules which manipulate bounds (X,L,U) constraints, 
ne bounds(X,L,U) ==> U >= L. 

red bounds(X,Ll,Ul) \ bounds (X,L2,U2) <=> LI >= L2, Ul <= U2 I true. 

int bounds(X,Ll,Ul) , bounds (X,L2,U2) <=> bounds (X,max(Ll ,L2) ,min(Ul ,U2) ) . 

For the 4th and 5th occurrences in rule int the implication 

{Xi = A 3L24, U2ibounds{Xi, L2i, U2i)) UUboundsiX^, LI5, UU) 

(where we use subscripts to indicate which is the active occurrence) holds. Hence, 



^ Note that later compiler passes remove the overhead of chain rules and empty rules. 
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the 5th occurrence will never succeed if the 4th fails. Since if the 4th succeeds the 
active constraint is deleted, the 5th occurrence can be omitted entirely. □ 

We can similarly improve success continuations. If we can prove for two consecu- 
tive occurrences {p{x), c, g) and {p{y), c', g') that |= -B${x = y hi3xChg) f\{3yc' hg')) 
then if the p{x) occurrence succeeds the p{y) occurrence will not. Hence, the success 
continuation oip{x) can skip the p{y) occurrence. Again, we can use whatever form 
of reasoning we please to prove the unsatisfiability. Clearly, this is only of interest 
when the p{x) occurrence does not delete the active constraint. 

Example 7 

Consider the two occurrences of p/2 in the rules: 

p(X,Y), q(Y,Y,X,T) ==> X >= Y I ... 
r(A,B,C), p(C,D) ==> C < D I ... 

The constraint X = C^Y = DA{3Tq(Y,Y,X,T)AX > Y) A{3 A, B,C r {A, B,C) A 
C < D) is clearly unsatisfiable and the success continuation of the first occurrence 
of p/2 can skip the second. □ 

Currently the HAL CHR compiler performs very simple fail continuation opti- 
mization based on basic implication reasoning about identical constraints and true. 
Furthermore, because of some subtle complications arising from the implementa- 
tion of universal searches, the current HAL CHR compiler restricts continuation 
optimization to existential searches. The diSiculty stems from deciding if the head 
of the rule fires or not, which is information that this optimization relies upon. For 
the existential case there is no problem, since matching is already a mere semidet 
test. However a universal search may succeed multiple times, so some additional 
mechanism for recording the number of times a rule fires must be introduced. One 
possible solution is thread a counter through the code for the universal search, 
and count the number of times the search succeeds. If the counter is zero after the 
universal search code exists, then proceed with the fail continuation, otherwise pro- 
ceed with the success continuation. This approach may be implemented in future 
versions of the compiler. 

4-2 Late Storage 

The first action in processing a new active constraint is to add it to the store, so 
that when it fires, the store has already been updated. In practice, this is inefficient 
since it may quite often be immediately removed. We can delay the addition of the 
active constraint until just before executing a right-hand-side that does not delete 
the active constraint, and can affect the store (i.e., may make use of the CHR 
constraints in the store). 

Example 8 

Consider the compilation of gcd/1. The first and third occurrences delete the ac- 
tive constraint. Thus, the new gcd/1 constraint need not be stored before they 
are executed. It is only required to be stored just before the code for the second 
occurrence. The call to gcd_insert_constraint can be moved to the beginning 
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gcd(N) :- 

new_constraint_number (CNl) , 

gcd_l(N,CNl) . 
gcd_l(N,CNl) :- 

(N = -> %7, Guard 
true, 7.7. RHS 

true /,'/, success continuation 
gcd_3(N,CNl) 7.7, fail continuation 

). 

gcd_3(M,CNl) :- 

(gcd_index_exists_iteration(N,CN2) , 
M >= N, CNl != CN2 -> 7.7. guard 
gcd_delete_constraint(M,CNl) , 
gcd(M-N) , 7.7. RHS 
true '/,"/, success continuation 

gcd_2(M,CNl) 7.7, fail continuation 

). 

gcd_2(N,CNl) :- 

gcd_index_init_iterator (10) , 
gcd_2_f orall.iterate (N , CNl , 10) . 
gcd_2_forall_iterate(N,CNl,I0) :- 
gcd_iteration_last (10) , 
gcd_insert_constraint(N,CNl) . 
gcd_2_forall_iterate(N,CNl,I0) :- 

gcd_it erat ion_next ( 10 , M , CN2 ,11), 
(M >= N, CNl != CN2 -> "/.•/. guard 
gcd_delete_constraint(M,CN2) , 
gcd_insert_constraint(N,CNl) , 7,7. late insert 
gcd(M-N) 7.7, RHS 

true 7.7. rule did not apply 

), 

(gcd_alive(CNl) -> 

gcd_2_f orall.iterate (N.CNl , II) 

true 

). 

Fig. 6. Simplified code for gcd/1 with late storage 

of gcd_2, while the calls to gcd_delete_constraint in gcd_l and gcd_3 can be 
removed. This simplifies the code for gcd/1 considerably, as illustrated in FigurelHI 

□ 

The current implementation infers this information by a simple pre-analysis. We 
can consider a rule that does not delete the active constraint as rhs- affects- store 
if its right-hand-side calls a CHR constraint, or a local predicate which calls CHR 
constraints (directly or indirectly), or (to be safe) an external predicate which is 
not a library predicate. In future compiler implementations, when CHR constraints 
are allowed to have non-ground arguments, we must also ensure no left-hand-side 
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variables can ever be bound by the right-hand-side. This is because the CHR execu- 
tion semantics dictate that whenever the instantiation state of a constraint changes, 
we must immediately run that constraint again as the active. However since the 
current implementation only supports ground CHR constraints, this issue is not yet 
relevant. 

Good late storage analysis is very important because most of the other analysis 

listed in this paper depends on it. Analysis for detecting set semantics, functional 
dependencies, never stored constraints and symmetry all rely on late storage infor- 
mation. 

4-3 Never Stored 

A rule of the form 

c )' , . . . , 

where c is a single constraint, always eliminates constraints of form c from the store. 
In particular if c is the most general form of the constraint p{xi, . . . , Xi.)J and p/fc 
does not need to be stored because of earlier occurrences of p/fc in rhs-affects-store 
rules, then we don't need to store this constraint at all. The advantage of never- 
stored information is that any rules involving p/A; will only wake up when c is the 
active constraint. The current implementation searches for instances of never-stored 
rules and uses this information to avoid unnecessary joins, and to avoid building 
redundant index structures. 

Example 9 

Consider a fixed/ 1 constraint which succeeds if its argument is a variable with 
equal lower and upper bounds, defined by the rules: 

bounds (X,V,V) \ fixed (X) <=> true, 
fixed (X) <=> fail. 

Both rules delete the active fixed/1 constraint. Thus, there will never be a fixed/1 
constraint in the store and hence an active bounds/3 constraint will never match 
the rule. Thus, the occurrence of bounds/3 in this rule will not be considered when 
compiling bounds/3. □ 

4-4 Set semantics 

Although CHRs use a multiset semantics, often the constraints defined by CHRs 
have a set semantics. The current implementation detects two different forms of 
set semantics. Either the program rules ensure duplicate copies of constraints are 
always deleted or duplicate copies will not affect the behaviour of the program. 
The distinction between the two forms affects how the compiler takes advantage of 
this information, but in both cases set semantics allows us to choose more efficient 
index structures. 

^ All arguments are pair-wise different variables. 
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A constraint p/k has set semantics if there is a rule which explicitly removes 
duphcates of constraints. That is, if there exists a rule of the form 

p{xi,...,Xk) l\] p{yi,---,yk) <s=^ g\di,...,dm 

such that \= Xi = yi A ■ ■ ■ Xk = yk ^sugg which occurs before any rules require 
p/k to be stored. 

Example 10 
The rule 

bounds(X,Ll,Ul) \ bounds (X,L2,U2) <=> LI >= L2, U2 >= Ul I true. 

ensures that any new active bound.s/3 constraint identical to one already in the 
store will be deleted (it also deletes other redundant bounds information). Since 
it occurs before any rules requiring bounds/3 to be stored the constraint has set 

semantics. □ 

A constraint also has set semantics if all rules in which it appears behave the 
same even if duplicates are present. This is a very common case since CHRs are used 
to build constraint solvers which (by definition) should treat constraint multisets 
as sets. Thus, a constraint p/fc also has set semantics if 

1. there are no rules which can match two identical copies of p/A: 

2. there are no rules that delete a constraint p/fc without deleting all identical 
copies. An exception is when the right-hand-side of such a rule always fails. 

3. there arc no rules with occurrences of p/fc that can generate constraints (on 
the right-hand-side) which do not have sot semantics. 

The current implementation uses a simple fixpoint analysis which can detect such 
constraints starting from the assumption that all constraints have set semantics. In 
each iteration a constraint which violates one of the rules above is deleted from the 
candidate set of those with set semantics. The iterations proceed until a fixpoint is 
reached. 

For constraints p/fc having this form we can safely add a rule of the form 

p{xi,...,Xk)\p{xx,...,Xk) ^s=^ true. 

This will avoid redundant work when duplicate constraints are added. We can also 
modify the index structures for this constraint to avoid the necessity of storing 
duplicates. 

Example 11 

Consider a constraint eq/2 (for equality) defined by the CHR 

eq(X,Y) , bounds (X,LX,UX) , bounds (Y,LY,UY) ==> bounds (Y,LX,UX) , bounds (X,LY,UY) . 

Then, since bounds/3 has set semantics, eq/2 also has set semantics. If we add the 

additional rule 

eq(X,Y) , X != Y <=> fail. 

then eq/2 still has set semantics. Even though the additional rule might delete 
one copy only of the constraint eq/2, it does not matter because the rule leads to 
failure. □ 
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Example 12 

Adding the additional rule which deletes identical copies of constraints can improve 
the termination of the program. Consider the following rules which define symmetry 
for ! = constraints 

neqset (§X !=Y\X !=Y <=> true, 
neqsym (§ X != Y ==> Y != X. 

If we delete the rule neqset then rule neqsym is an infinite loop for any new !=/2 
active constraint. However if !=/2 implicitly has set semantics, then we will auto- 
matically add the rule neqset, hence the program becomes terminating. □ 

5 Determining Functional Dependencies and Symmetries 

In previous sections we have either explained how to determine the information used 
for an optimization (as in the case of rules which arc rhs-affects-store) or assumed it 
was given by the user or inferred by the compiler in the usual way (as in type, mode 
and determinism). The only two exceptions (functional dependencies and symme- 
tries) were delayed in order not to clutter the explanation of CHR compilation. The 
following two sections examine how to determine these two properties. 

5.1 Functional Dependencies 

Functional dependencies occur frequently in CHRs since we encode functions using 
relations. Suppose p/fc need not be stored before occurrences in a rule of the form 

p{xi,...,xuyi+i,...,yk)l\]p{xi,...,xuzi+i,...,Zk) <^ di,...,d^ (1) 

where Xi, \ < i < I and yi, Zi,l + I < i < k are distinct variables. This corresponds 
to the functional dependencies p{xi, . . . ,Xk) '.■ {xi, . . . ,xi) Xi,l + 1 < i < k. 
For example, the rule int of Example illustrates the functional dependencies 
bounds{X, L,U) :: X L and bounds{X, L,U) :: X U. In addition, rule 
CQ) deletes identical copies ensuring p/fc has set semantics. Therefore there is at 
most one constraint in the store of the form p{xi, a;;, _) at any time. 

Likewise, any constraint p/fc that has a rule which deletes identical copies of con- 
straints can also be thought of as having the functional dependency p{xi, . . . , Xk) .' 
{xi,. . . ,Xfc) 0. 

Another common way functional dependencies are expressed in CHRs is by rules 
of the form 

p{xi, . . . ,xi,yi+i, . . . ,yk),p{xi, . . . ,xi, zi+i, . . . ,Zk) =^ yi+i =zi+i,...yk = Zk 

This leads to the same functional dependency as before, however it does not lead 
to set semantics behavior. 

We can detect more functional dependencies if we consider multiple rules of the 
same kind. For example, the rules 

p{xi, . . . , xi,yi+i, ...,yk)[, \]pixi, ...,xi, . . . , Zk) 9i\di, .-.^dm 

p{xi, . . . ,xi,y'i+j^, . . . ,y'k)l\]p{xi, . . . ,xi,z'i^j^, . . . , z'k) g2\d[, . . . , d'„, 
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also lead to functional dependencies if \= {y = y' A z = z' ^ {gi V g^) is provable. 
However because of the difficulty in solving disjunctions, the current analysis is 
limited to the case where gx and g2 are primitive integer or real constraints (not 
conjunctions of other constraints). 

Example 13 

The second rule for gcd/1 written twice illustrates the functional dependency 
gcd(Af) :: ^ AT since N = M' A M = N' (M > N V M' > N') holds: 

gcd(N) \ gcd(M) <=> M >= N I gcd(M - N) . 
gcd(N') \ gcd(M') <=> M' >= N' I gcd(M' - N'). 

Making use of this functional dependency for gcd/1 we can use a single global 
yesno integer value ($Gcd) to store the (at most one) gcd/1 constraint, we can 
replace the forall iteration by exists iteration, and remove the constraint numbers 
entirely. The resulting code (after unfolding) is 



gcd(X) :- 

(X = -> true 17. occ 1 

; (yes(N) = $Gcd, X >= N •/./. occ 3 

gcd(X-N) y;/. occ 3 

; (yes(M) = $Gcd, M >= X 11 occ 2 

$Gcd := yes(X), H occ 2 

gcd(M-X) 17. occ 2 



guard -> rhs 

gcd_index_exists_iteration, guaird 
rhs 

gcd_f orall-iterate, guard 
gcd_insert_constraint 

rhs 



; $Gcd : = yes (X) ) ) ) . "/.•/. late insert 

□ 



5.2 Symmetry 

Symmetry also occurs reasonably often in CHRs. There are multiple ways of de- 
tecting symmetries. A rule of the form 

p{Xi,X2,-.-,Xk) =^ p{X2,Xi, . . . ,Xk) 

that occurs before any rule that requires p/fc to be inserted induces a symme- 
try for constraint p{xi, . . . ,Xk) on xi and X2, providing that no rule eliminates 
p{xi,X2, ■■■,Xk) and not p{x2,xi, . . .,Xk). 

Example 14 

Consider a ! =/2 constraint defined by the rules: 

neqset @X !=Y\X !=Y<=> true, 

neqsym OX != Y ==> Y != X. 

neqlower OX != Y, bounds (X,VX,VX) , bounds (Y,VX,UY) ==> bounds (Y,VX+1 ,UY) . 

nequpper OX != Y, bounds (X,VX,VX) , bounds (Y,LY,VX) ==> bounds (Y, LY, VX-1 ) . 

the rule neqsjnn QX !=Y=>Y !=X illustrates the symmetry of !=/2 w.r.t. X 
and Y, since in addition no rule deletes a (non-duplicate) ! =/2 constraint. □ 

A constraint may be symmetric without a specific symmetry adding rule. The 
general case is complicated and, for brevity, we simply give examples. 
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Example 15 

The rule in Example 1111 and its rewriting with {X Y,Y ^ are logically 
equivalent (they are variants illustrated by the reordering of the rule). 

eq(X,Y) ,bounds(X,LX,UX) .bounds (Y.LY.UY) ==> bounds(Y,LX,UX) ,bounds(X,LY,UY) . 
eq(Y,X) ,bounds(Y,LY,UY) , bounds (X.LX.UX) ==> bounds (X.LY.UY) ,bounds(Y,LX,UX) . 

Hence, since this is the only rule for eq/2, the eq/2 constraint is symmetric. □ 
Example 16 

The following rules remove redundant inequalities: 

eq(X,Y) \ X <= Y <=> true. 
eq(Y,X) \ X <= Y <=> true. 

They are symmetric for eq{x,y) on x and y. □ 

If every rule containing constraint p/fc is symmetric on xi and X2 with another 
rule then, the constraint is symmetric on xi and X2. Hence eq(a;,?/) is symmetric in 
X and y. 

Note that we can take into account symmetries in other constraints when proving 
symmetry of rules. Hence for example the additional rule 

X != Y, eq(X,Y) ==> fail. 

is symmetric for eq(a::,?/) on x and y because of the symmetry of !=/2. 

Note that we can find more symmetry by starting from the assumption that every 
constraint is symmetric on all arguments and iteratively disproving this. 

6 Experimental Results 

The initial version of the HAL CHR compiler (reported in IIHolzbaur et al. 2001|l ) 
realized only some of the optimizations discussed herein, continuation optimization, 
simplistic join ordering and simplistic late storage. The current version fully imple- 
ments most of the analysis and optimizations discussed in this paper, including 

• early guard scheduling and join ordering; 

• the discovery of functional dependencies, set semantics and symmetries (only 
the first case of symmetry is detected); 

• late storage; and 

• the building of specialized indexes which rely on this information. 

Analysis is performed in an independent compilation phase, followed by an op- 
timized code generation phase which builds the index structures amongst other 
things. Further improvements in the analysis phase are possible, such as better dis- 
covery of symmetries (implied from rules) and improved continuation optimization. 
Further improvements are also possible in the optimized code generation phase, such 
as generating multiple indexes for every lookup (currently, the compiler generates 
one index per constraint). 

The cost of the CHR analysis is small compared with the cost of other tasks 
performed by the HAL compiler, such as type and mode analysis. The discovery 
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of functional dependencies, set semantics and symmetries is generally very cheap 
since only a linear pass over the program is required. Late storage is slightly more 
expensive since a call graph must be constructed. Join ordering is potentially ex- 
pensive for rules with a large number of partners in the head, however the current 
implementation uses a greedy algorithm which is generally much faster. 

The currently implementation is a prototype designed to demonstrate how an 
optimizing CHR compiler will eventually be realized. To test the analysis and op- 
timizations implemented by the prototype we compare the performance on 3 small 
programs: 

• gcd as described in the paper, where the query (a, 5) is gcd(a) ,gcd(6). 

• interval: a simple bounds propagation solver executing N-queens; where 
the query (a, b) is for a queens with each constraint added b times (usually 
1, just here to illustrate the possible benefits from set semantics). The full 
code for the bounds propagation solver (module interval) can be found in 
in Appendix [Appendix A| 

• dfa: a visual parser for deterministic finite automatas (DFAs) building the 
DFA from individual graphics elements, e.g. circles, lines and text boxes. The 
constraints are all ground, and the compilation involves a single (indexable) 
lookup line{-,Y), has a single symmetry line{X,Y) — line{Y,X) and no 
constraints (except line/2) have set semantics. In this program the rules are 
large multi-ways joins, e.g., the rule to detect an arrow from one state to 
another is: 

circle(Cl,Rl), circle (C2 ,R2) \ 

line (PI, P2), line (P2, PI), line(P3,P2), line(P2,P3), 

line(P4,P2), line(P2,P4), text(P5,T) <=> 

point_on_circle(Pl,Cl,Rl) , point_on_circle(P2,C2,R2) , 
midpoint(Pl,P2,P12) , near(P12,P5) I arrow (PI ,P2,T) . 

Notice that the rule is careful to delete symmetric copies of the constraint 
line/2. The query a finds a (constant) small DFA (of 10 elements) in a large 
set of a redundant arrows (each consisting of three lines and a text box) . 

A summary of the results from the analysis phase are shown in Figure ^ For 
the gcd program, the analysis infers® the functional dependency X and set 
semantics from the rule 

gcd(N) \ gcd(M) <=> M >= N I gcd(M-N) . 

The compiler uses this information to build a yesno index structure, since the 
functional dependency combined with set semantics implies that only one gcd (A) 
constraint can ever be in the store at one time. 

The next program, interval, is the most fruitful in terms of information discov- 
ered. The rules 

bounds(X,Ll,Ul) \ bounds (X,L2,U2) <=> LI >= L2, U2 >= Ul I true. 
bounds(X,Ll,Ul) , bounds (X,L2,U2) <=> bounds(X,max(Ll ,L2) ,min(Ul ,U2) ) . 

* See example in Section l5.1l 



24 C. Holzhaur & M. Garcia de la Banda & P.J. Stuckey & G.J. Duck 



Table 1. Summary of the information extracted by the analysis phase of CHR 
compilation 



Program 


Constraint 


FD 


Set 


Sym 


gcd 


gcd(X) 


X 


yes 




interval 


bounds (X,L,U) 


{X} ^ L,U 


yes 




interval 


eq(X,Y) 




yes 




interval 


geq(X,Y) 




yes 




interval 


X != Y 




yes 


{X,Y} 


interval 


plus(X,Y,Z) 




yes 




dfa 


line(X,Y) 




yes 


{X,Y} 



leads to the the discovery of the set semantics of bounds /3 and the functional 
dependencies bounds{X, L,U) : X L and bounds{X, L,U) : X ^ U. Therefore 
only one copy of the constraint bounds (X,_,_) can ever be in the store at one time. 
The resulting structure for bounds/3 is a balanced 234 tree with {X) as the key 
and {L, U) as the value. 

All of the other interval constraints at least have set semantics. Set semantics 
are inferred for constraints that behave the same even if multiple copies are stored. 
For example, the only rule involving the constraint eq/2 is 

equals @ eq(X,Y), bounds(X,LX,UX) , bounds (Y.LY.UY) ==> 

bounds ( Y, LX, UX) , bounds (X, LY, UY) . 

Since bounds/3 has set semantics, then so has eq/2. The compiler uses this infor- 
mation to eliminate active eq/2 constraints that already occur in the store. Thus 
redundant work is avoided, and potentially the size of indexes is reduced. In addition 
symmetry on the constraint ! =/2 is detected because of the symmetric rule 

neqsym @ X ! = Y ==> Y != X. 

Because of the benefit with symmetric reduction, the compiler will choose a bal- 
anced 234 tree index for ! =/2 with {X, Y) as the key. 

Finally the dfa program turns out to be the least interesting in terms of infor- 
mation discovered. The only constraint with any useful attributes is line/2, which 
is symmetric and has set semantics. Again the compiler generates a balanced 234 
tree index (for the same reasons as !=/2 in the interval program). All other con- 
straints use the default unsorted list index structure. However, because of the large 
size of the heads of rules in the dfa program, the most important optimization is 
join ordering and early guard scheduling. 

The results gcd, interval and dfa are shown in Table |21 Tableland Table 01 
respectively. All timings are the average over 20 runs on a 1200MHz AMD Athlon 
Processor with 1Gb of RAM running under Debian GNU Linux 3.0 with kernel 
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Table 2. Execution times (ms) for various optimized versions of the gcd program 



Benchmark Query Orig +yesno +det Hand 



gcd (5000000,3) 1111 976 402 50 

gcd (10000000,3) 2314 2032 803 93 

gcd (50000000,3) 12412 11093 5095 475 



gcd (100000000,3) 24891 22240 10270 961 



Table 3. Execution times (ms) for various optimized versions of the interval pro- 
gram 



Benchmark 


Query 


Orig 


-l-tree 


-l-det 


-|-sym 


-l-eq 


interval 


(12,1) 


389 


138 


126 


67 


68 


interval 


(15,1) 


1312 


382 


355 


172 


169 


interval 


(20,1) 


6077 


1602 


1535 


693 


677 


interval 


(30,1) 


73158 


11728 


12537 


4943 


4916 


interval 


(12,2) 


556 


184 


167 


107 


69 


interval 


(15,2) 


1824 


532 


471 


283 


167 


interval 


(20,2) 


8658 


2148 


1984 


1135 


669 


interval 


(30,2) 


110224 


21950 


18799 


8522 


5071 


Tabk' 4. Ex(X'ution tim(^s (ms) for various 


optimiz(xi v(Tsions of tlw^ dfa program 


Benchmark 


Query 


Prolog 


+join 


-|-treesym 


-l-det 


dfa 


20 


4987 


30 




20 


19 


dfa 


50 


69070 


164 




87 


86 


dfa 


100 


532278 


612 




271 


267 


dfa 


200 


too long 


2804 




1525 


1536 


dfa 


400 


too long 


13058 




7401 


7370 



version 2.2.19, and arc given in milliseconds. Any test taking more than 600000ms 
(10 minutes) is marked as "too long". 

For gcd we first give times for the original output of the compiler Orig (uses a 
list index). In the version +yesno the list storage of constraints is replaced by a 
+yesno structure (using the hmctional dependency and set semantics). We can see 
a modest improvement here by just avoiding some overhead. Note that in Orig the 
list index for gcd/2 never grows more than one item in length anyway, so we do not 
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expect a significant improvement by replacing a singleton list with a yesno struc- 
ture. In +det the determinism declarations of the compiled CHR code is altered 
to take into account the functional dependency. This is a low level optimization in 
which previously "nondeterministic" lookups can be declared semidet (can succeed 
at most once). Without this optimization they are declared cc_nondet which means 
although they may succeed more than once we are interested only in the first solu- 
tion. This produces faster executable code since deterministic (including semidet) 
code can be compiled in a simpler way than nondeterministic code. Finally Hand 
uses the hand optimized implementation of gcd/1 shown in Example ll3l Here we see 
a considerable improvement purely from removing all of the overhead generated by 
the compiler (such as constraint numbers). We expect that future implementations 
of the compiler will be able to remove most of this excess overhead. 

The second experiment we show is interval in Table |21 The original code Orig 
uses list indexes for all constraints, version +tree is where the list index on bounds/S 
has been replaced by a 234 tree index (using the functional dependency), +det 
where some cc_nondet searches are correctly declared semidet, +sym where the 
list index on ! =/2 has been replaced by a 234 tree index (because we can take 
advantage of symmetric reduction), and +eq where identical copies of set semantic 
constraints are deleted. Here we can see a significant improvement when the list 
index for bounds/3 is replaced by a 234 tree index. This is not surprising, since we 
are replacing 0{n) lookups (for lists) with 0(log(n)) lookups (for trees). Next the 
+det optimization provides a slight improvement in most cases. However for some 
unknown reason the test (30, 1) actually becomes slightly worse. Next the +sym 
lets us take advantage of symmetric reduction, which means we can choose a 234 
tree index for the constraint !=/2. Again this provides a significant improvement. 
Finally the +eq optimization deletes identical copies of constraints before they run 
as the active constraint. The handling of set semantics is of considerable benefit 
when duplicate constraints are actually added, and doesn't add significant overhead 
when there are no duplicate constraints, hence it seems worthwhile. 

The final example is the dfa program in Table 21 The code Prolog has the de- 
fault join ordering and guard scheduling used by existing Prolog implementations of 
CHR compilers. Recall that this means guards are tested strictly after the join op- 
eration, hence the dreadful performance on a program with large rules, such as the 
dfa example. For the previous examples the default join ordering and the best join 
ordering coincide. Enabling join ordering and early guard scheduling {+join) pro- 
duces a massive improvement in running time (dfa 100 is nearly 2000 times better). 
This highlights the importance of this optimization. Next +treesym turns on 234 
tree indexes and symmetric lookup reduction for the line/2 constraint (without 
the symmetry lookup reduction, the compiler will not choose to use a 234 index be- 
cause of a lookup line{_,Y)). Once again we get a significant improvement. Finally 
in this case the +det optimization seems to produce a very slight improvement, if 
at all. 

Finally we remark that it is easy to optimize a very poor base implementation 
of CHRs. The HAL base implementation is highly efficient. The execution times of 
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the Orig or Prolog columns are about an order of magnitude faster than CHRs in 
SICStus Prolog. See (,Holzbaur et al. 2001,1 for more detail. 

7 Conclusion and Future Work 

The core of compiling CHRs is a multi-way join compilation. But, unlike the usual 
database case, we have no information on the cardinality of relations and index 
selectivity. We show how to use type and mode information to compile efficient 
joins, and automatically utilize appropriate indexes for supporting the joins. We 
show how set semantics, functional dependencies and symmetries can improve this 
compilation process. We further investigate how, by analyzing the CHRs themselves 
we can find other opportunities for improving compilation, as well as determined 
functional dependencies, symmetries and other algebraic features of the CHR con- 
straints. The prototype HAL CHR compiler which applies these techniques produces 
highly efficient CHR executables. 

Almost all of the optimizations considered in this paper are not specific to HAL, 
the optimizations that are not immediately applicable in a CHR compiler for Prolog 
are as follows. Mode information is not available for guards which means early guard 
scheduling may not be as effective, still assuming all variables are invars is safe and 
will account for most of the improvement. The determinism optimization +det in 
the experiments is not applicable since determinism declarations are not supported 
by Prolog systems. 

There is substantial scope for further optimization of CHRs. These include: more 
complicated lookups (for example range lookups on tree indexes) , replacing propa- 
gation rules by equivalent simplification rules, common subexpression elimination, 
unfolding of CHRs, and determining invariant information for stored constraints. 
We plan to continue improving the HAL CHR compiler to take advantage of these 
possibilities. 
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Appendix A Building a constraint solver in HAL using CHRs 

The program in Figure IXTI defines a simple bounds propagation solver for integers using 
constraint handling rules. From a HAL perspective it is a solver module defining a solver 
on the type cint. Line (1/3) is the type definition for the new type cint which is a wrapped 
integer. The integer is used as a variable number. The integer is wrapped so that we have 
a new type that we can (re-)define equahty for. The type is exported abstractly hence its 
definition is not visible outside the module, thus restricting operations on cint to those 
in this module. 

Line (1/4) is a re-instantiation declaration, which is required because we are going to 
treat cints in two ways. The reinst_old declares a new instantiation cold (to be associ- 
ated with the cint type) which is equivalent to "old" (i.e. a possibly non-ground term) 
outside the module, and equivalent to ground inside the module. We require this because 
outside the module we treat cints as bounds propagation solver variables, whereas in- 
side the module they will be manipulated as wrapped integers (which are ground). Lines 
(L5) — {L6) give two common modes of usage for cints. 

Variable numbers (for new cints) are kept track of in a global integer counter VarNum. 
This is declared in line {L7) with its type int, and initial value (0). 

For any solver type we need to define two predicates init/1 which initializes a new 
variable and =/2 for equating two solver variables. Line (1/8) is the predicate declaration 
for init/1 which is exported. Its mode is given in line (1/9), the mode cno takes a new 
object and returns a cold object (old outside this module, and ground inside this module). 
Its definition in the next line simply returns the wrapped counter value, and increments 
the counter. The predicate must always succeed exactly once hence its determinism is det, 
but to pass determinism checking the call to bounds/3 is wrapped in an if-then-else (since 
the compiler cannot determine that it will not fail). 

The =/2 predicate is defined in line (LIO) as export_only, which makes it visible outside 
the module, but not visible inside the module. This is to avoid confusion with the equality 
on the internal view of cints which simply treats them as ground terms rather than integer 
variables. Its mode definition in line (Lll) takes two cold cints as input and returns the 
same instantiation (the coo mode). It may fail, so the determinism is semidet. Note the 
definition of =/2 is made in terms of the non-exported constraint eq/2. 

Finally we arrive at our first constraint. Line (1/12) defines an exported constraint 
bounds/3 which relates a cint to two ints. The mode declaration on line {L13) declares 
that the constraint must be invoked with an old cint and two ground integers. The CHR 
non_empty is a simple propagation rule. Note the advantages of a typed language, the >= 
on the right hand side is integer comparison, not to be confused with the constraint >= 
defined on line (L16). The CHR redundant removes redundant bounds constraints. The 
CHR intersect replaces two bounds/3 constraints on the same variable by one. Note that 
bounds/3 occurs in many of the rules in the program not just the two defined immediately 
below its declaration. 

When compiling the module interval we can determine the functional dependencies: 
bounds{X, L,U) :: X L and bounds{X, L,U) :: X U, the symmetries eq{X,Y) = 
eq{Y, X), neq{X, Y) = neq{Y, X) and plua(X, Y, Z) = plua(Y, X, Z) and that each of the 
CHR constraints has a set semantics. 

The lookups required for the program are (after reduction by functional dependencies) : 
bounds{X,_,S), eq{X,), eg(_,Y'), neq{X,Y), neq{X,), neq{-,Y), plus{X,_,S), plus{-,Y,S) 
and plus{_, Z). Symmetry eliminates the indexes eg(_, Y), neq{_, Y) and plus{_, Y, _). 
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:- module interval. (LI) 
: - import int . 

:- export_abstract typedef cint -> f(int). (^3) 

:- reinst_old cold = ground. (^4) 

: - modedef cno -> (new -> cold) . {L5) 

:- modedef coo -> (cold -> cold). (L6) 

:- VeirNum glob_var int = 0. (L7) 

:- export pred init(cint). (^8) 

:- mode init(cno) is det . (^9) 
init(V) :- V = f ($VarNuiii) , $VarNum := $VarNum + 1, 

(bounds (V, -10000, 10000) -> true ; error ("not det.")). 

:- export_only pred cint=cint. (^10) 
:- mode coo=coo is semidet. (^11) 

X = Y :- eq(X,Y) . 

:- export chrc bounds (cint , int , int) . {L12) 
:- mode bounds (coo, in, in) is semidet. (^13) 

non_emptyQ boimds (X,L,U) ==> U >= L. 
redundanta bounds (X, LI, Ul) \ bounds (X,L2,U2) <=> 

LI >= L2, U2 >= Ul I true. 
intersect<abounds(X,Ll,Ul) , bounds (X,L2,U2) <=> 



bounds(X,max(Ll,L2) ,min(Ul,U2)) . 

:- chrc eq(cint , cint) . 
:- mode eq(in,in) is semidet. 

equals @ eq(X,Y), bounds (X, LX, UX) , bounds (Y,LY,UY) ==> 
bounds ( Y , LX , UX) , bounds (X , LY , UY) . 

:- export chrc cint >= cint. 
:- mode coo >= coo is semidet. 

geq X >= Y, bounds (X, LX, UX) , bounds (Y,LY,UY) ==> 
bounds ( Y , LX , UY) , bounds (X , LX , UY) . 

:- export chrc cint != cint. 
:- mode coo != coo is semidet. 

neqset @ X!=Y\X!=Y<=> true, 
neqsym X != Y ==> Y != X. 

neqlower® X != Y, bounds (X,VX,VX) .bounds (Y,VX,UY) ==>bounds (Y,VX+1 ,UY) . 
nequpperO X != Y,bounds(X,VX,VX) ,bounds(Y,LY,VX)==>boiuids(Y,LY,VX-l) . 

:- export func cint + cint — > cint. 

:- mode coo + coo — > oo is semidet. 

X + Y — > Z :- plus(X,Y,Z) . 

:- chrc plus (cint , cint , cint) . 

:- mode plus (in, in, in) is semidet. 

plusa plus(X,Y,Z) , bounds (X,LX,UX) , bounds (Y,LY,UY) , bounds (Z ,LZ ,UZ) ==> 

bounds (X,LZ-UY,UZ-LY) ,bounds(Y,LZ-UX,UZ-LX) ,bounds(Z,LX+LY,UX+UY) . 



(L14) 
(L15) 



(L16) 
(L17) 



Fig. A 1. A simple integer bounds propagation solver using CHRs 



